Domain-Driven Design，DDD
我理解，DDD非常适合应用于偏业务的中大型复杂项目迭代中，尤其是电商之类的web项目。基于业务架构的系统设计，再完美匹配微服务架构，可以达到业务维度的高度统一。
我的学习沉淀
领域驱动设计
- 实例: 领域模型(抽象逻辑) ：抽象/封装 数据+行为
- 方法：分治、抽象、知识(DDD提供了这样的知识手段，让我们知道如何抽象出限界上下文以及如何去分治)
- 限界上下文—>微服务边界划分，从业务维度做分治。上下文是领域的解系统，映射到团队，高效协作
- 核心上下文
- 支撑上下文
- 通用上下文
- 防腐层ACL，适配&提供访问机制。
- 耦合程度控制在数据耦合层(数据库)
核心诉求：将业务架构映射到系统架构，想呼应。
微服务，则追求业务层面的复用
系统结构与组织结构 对齐，保持一致。
战术设计：数据+行为
- 实体 Entity (标识区分(唯一)的对象)，有状态
- 值对象 Value Object (值描述的对象，不唯一)
- 聚合根 Aggregate，Aggregate Root，根实体
- 领域服务：Service，领域抽象功能点的实现。serverless处理流程，无状态
- 领域事件：通常是用来与其他聚合解耦的，采用观察者模式，一个聚合订阅另外一个聚合的事件。
- 库Repository：持久聚合，redis
- 工厂：创建聚合根 or 实体 or 值对象
- 模块：命名空间，概念隔离
在前端的业务域-如何实践DDD？
挖个坑